<div class="tmd-doc">
<h1 class="tmd-header-1">
Go Details 101
</h1>
<p></p>
<div class="tmd-usual">
Index:
</div>
<p></p>
<ul id="details.html" class="tmd-list summaries">
<li class="tmd-list-item">
<div class="tmd-usual">
Code package related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#import-package-multiple-times">A package can be imported more than once in a source file.</a>
</div>
</li>
</ul>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Control flow related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#default-branch-position">The <code class="tmd-code-span">default</code> branch in <code class="tmd-code-span">switch</code> and <code class="tmd-code-span">select</code> blocks can be put before all <code class="tmd-code-span">case</code> branches, after all <code class="tmd-code-span">case</code> branches, or between <code class="tmd-code-span">case</code> branches.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#constant-case-expressions">The numeric constant case expressions in a <code class="tmd-code-span">switch</code> block can't be duplicate, but boolean ones can.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#switch-expressions-are-typed">The switch expressions in <code class="tmd-code-span">switch</code> block are always evaluated to typed values.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#default-switch-expression-value">The default switch expression of a <code class="tmd-code-span">switch</code> block is a typed value <code class="tmd-code-span">true</code> of the predeclared type <code class="tmd-code-span">bool</code>.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#open-brace-on-the-next-line">Sometimes, the open brace <code class="tmd-code-span">{</code> of an explicit code block can be put on the next line.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#some-case-branch-blocks-must-be-explicit">Some <code class="tmd-code-span">case</code> branch blocks must be explicit.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#defer-modify-results">Nested deferred function calls can modify return result values of nesting functions.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#no-op-recover-calls">Some <code class="tmd-code-span">recover</code> calls may be no-ops.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#os-exit-runtime-goexit">Exit a program with a <code class="tmd-code-span">os.Exit</code> function call and exit a goroutine with a <code class="tmd-code-span">runtime.Goexit</code> function call</a>.
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Operator related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#some-operator-precedence">The precedence of the increment operator <code class="tmd-code-span">++</code> and the decrement <code class="tmd-code-span">--</code> is lower than the dereference operator <code class="tmd-code-span">*</code> and the address-taking operator <code class="tmd-code-span">&amp;</code>, which are lower than the property selection operator <code class="tmd-code-span">.</code> in selectors.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#type-deduction-in-bit-shift">The type deduction rule for the left untyped operand of a bit-shift operation depends on whether or not the right operand is a constant.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Pointer related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#conversion-of-pointers-with-different-underlying-types">Values of two pointer types with different underlying types can be converted to each other if the base types of their underlying types share the same underlying type.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#addresses-of-zeor-sized-values">Addresses of different zero-sized values may be equal, or not.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#self-based-pointer-type">The base type of a pointer type may be the pointer type itself.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#pointer-selector-shorthands">A detail about selector shorthands.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Container related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#composite-literal-simplification">Sometimes, nested composite literals can be simplified.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#use-pointer-as-array">In some scenarios, it is ok to use array pointers as arrays.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#nil-map-element-retrieving">Retrieving elements from nil maps will not panic. The result is a zero element value.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#nil-map-element--deletion">Deleting an entry from a nil map will not panic. It is a no-op.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#append-slice-elements">The result slice of an <code class="tmd-code-span">append</code> function call may share some elements with the original slice, or not.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#subslice">The length of a subslice may be larger than the base slice the subslice derives from.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#derive-from-nil-slice">Deriving a subslice from a nil slice is ok if all the indexes used in the subslice expression are zero. The result subslice is also a nil slice.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#range-over-nil-map-and-slice">Ranging over a nil maps or a nil slices is ok, it is a no-op.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#range-over-nil-array-pointer">Range over a nil array pointer is ok if the second iteration variable is ignored or omitted.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#modify-slice-length-and-capacity-separately">The length and capacity of a slice can be modified separately.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#indexes-in-composite-literals">The indexes in slice and array composite literals must be constants and non-negative.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#constant-keys-in-composite-literals">The constant indexes or keys in slice/array/map composite literals can't be duplicate.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#array-slice-element-addressability">Elements of unaddressable arrays are also unaddressable, but elements of unaddressable slices are always addressable.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#array-slice-derivable">It is ok to derive subslices from unaddressable slices, but not ok from unaddressable arrays. It is ok to take addresses for elements of unaddressable slices, but not ok for elements of unaddressable arrays.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#nan-as-map-keys">Putting entries with <code class="tmd-code-span">NaN</code> as keys to a map is like putting the entries in a black hole.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#capacity-of-slice-from-string">The capacity of the result slice of a conversion from a string to byte/rune slice may be larger than the length of the result slice.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#different-loops">For a slice <code class="tmd-code-span">s</code>, the loop <code class="tmd-code-span">for i = range s {...}</code> is not equivalent to the loop <code class="tmd-code-span">for i = 0; i &lt; len(s); i++ {...}</code>.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#map-entry-iteration">The iteration order over maps is not guaranteed to be the same from one iteration to the next.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#create-entry-in-map-entry-iteration">If a map entry is created during an iteration of the map, that entry may be iterated during the iteration or may be skipped.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Function and method related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#call-as-expression">A multi-result function call can't mix with other expressions when the call is used as the sources in an assignment or the arguments of another function call.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#compile-time-evaluated-calls">Some function calls are evaluated at compile time.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#method-as-function">Each method corresponds to an implicit function.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Interface related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#comparison-interfaces-may-panic">Comparing two interface values with the same dynamic incomparable type produces a panic.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#type-assertion-to-interface-type">Type assertions can be used to convert a value of an interface type to another interface type, even if the former interface type doesn't implement the latter one.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#failed-type-assertion-may-panic">Whether or not the second optional result of a failed type assertion is present will affect the behavior of the type assertion.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#impossible-to-interface-assertion">About the impossible to-interface assertions which can be detected at compile time.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#errors-new-different-returns">Two <code class="tmd-code-span">error</code> values returned by two <code class="tmd-code-span">errors.New</code> calls with the same argument are not equal.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Channel related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#receive-only-channel-canot-be-closed">Receive-only channels can't be closed.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#send-to-closed-channel-is-non-blocking">Sending a value to a closed channel is viewed as a non-blocking operation, and this operation causes a panic.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
More type and value related details:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#local-type-declaration">Types can be declared within function bodies.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#final-zero-size-field">For the standard compiler, zero-sized fields in a struct may be treated as one-byte-sized value.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#nan-inf">NaN != NaN, Inf == Inf.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#non-exported-names-from-different-packages">Non-exported method names and struct field names from different packages are viewed as different names.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#blank-fields-are-ignored-in-comparisons">In struct value comparisons, blank fields will be ignored.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Miscellanies:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#sometimes-parentheses-are-required">Parentheses are required in several rare scenarios to make code compile okay.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#stack-overflow-is-unrecoverable">Stack overflow is unrecoverable.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#some-evaluation-order-are-compiler-dependent">Some expression evaluation orders in Go are compiler implementation dependent.</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Standard packages related:
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#reflect-deep-equal">The results of <code class="tmd-code-span">reflect.DeepEqual(x, y)</code> and <code class="tmd-code-span">x == y</code> may be different.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#reflect-value-bytes">The <code class="tmd-code-span">reflect.Value.Bytes()</code> method returns a <code class="tmd-code-span">[]byte</code> value, which element type, <code class="tmd-code-span">byte</code>, might be not the same as the Go slice value represented by the receiver parameter.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#check-file-existent">We should use <code class="tmd-code-span">os.IsNotExist(err)</code> instead of <code class="tmd-code-span">err == os.ErrNotExist</code> to check whether or not a file exists.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#boolean-flag">The <code class="tmd-code-span">flag</code> standard package treats boolean command flags differently than number and string flags.</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#printf-positional-arguments"><code class="tmd-code-span">[Sp|Fp|P]rintf</code> functions support positional arguments.</a>
</div>
</li>
</ul>
</li>
</ul>
<p></p>
<div class="tmd-base summaries-items">
<p></p>
<h3 id="import-package-multiple-times" class="tmd-header-3">
A package can be imported more than once in a source file.
</h3>
<p></p>
<div class="tmd-usual">
A Go source file can imports the same package multiple times, but the import names must be different. These same-package imports reference the same package instance.
</div>
<p></p>
<div class="tmd-usual">
For example:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"
import "io"
import inout "io"

func main() {
	fmt.Println(&amp;inout.EOF == &amp;io.EOF) // true
}
</code></pre>
<p></p>
<p></p>
<h3 id="default-branch-position" class="tmd-header-3">
The <code class="tmd-code-span">default</code> branch in <code class="tmd-code-span">switch</code> and <code class="tmd-code-span">select</code> blocks can be put before all <code class="tmd-code-span">case</code> branches, after all <code class="tmd-code-span">case</code> branches, or between <code class="tmd-code-span">case</code> branches.
</h3>
<p></p>
<div class="tmd-usual">
For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">	switch n := rand.Intn(3); n {
	case 0: fmt.Println("n == 0")
	case 1: fmt.Println("n == 1")
	default: fmt.Println("n == 2")
	}

	switch n := rand.Intn(3); n {
	default: fmt.Println("n == 2")
	case 0: fmt.Println("n == 0")
	case 1: fmt.Println("n == 1")
	}

	switch n := rand.Intn(3); n {
	case 0: fmt.Println("n == 0")
	default: fmt.Println("n == 2")
	case 1: fmt.Println("n == 1")
	}

	var x, y chan int

	select {
	case &lt;-x:
	case y &lt;- 1:
	default:
	}

	select {
	case &lt;-x:
	default:
	case y &lt;- 1:
	}

	select {
	default:
	case &lt;-x:
	case y &lt;- 1:
	}
</code></pre>
<p></p>
<h3 id="constant-case-expressions" class="tmd-header-3">
The numeric constant case expressions in a <code class="tmd-code-span">switch</code> block can't be duplicate, but boolean ones can.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	switch 123 {
	case 123:
	case 123: // error: duplicate case
	}
}
</code></pre>
<p></p>
<div class="tmd-usual">
But the following program compiles okay.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	switch false {
	case false:
	case false:
	}
}
</code></pre>
<p></p>
<div class="tmd-usual">
For reasons, please read <a href="https://github.com/golang/go/issues/28357">this issue</a>. The behavior is compiler dependent. In fact, the standard Go compiler also doesn't allow duplicate string case expressions, but gccgo allows.
</div>
<p></p>
<p></p>
<h3 id="switch-expressions-are-typed" class="tmd-header-3">
The switch expressions in <code class="tmd-code-span">switch</code> block are always evaluated to typed values.
</h3>
<p></p>
<div class="tmd-usual">
For example, the switch expression <code class="tmd-code-span">123</code> in the following <code class="tmd-code-span">switch</code> block is viewed as a value of <code class="tmd-code-span">int</code> instead of an untyped integer. So the following program fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	switch 123 {
	case int64(123):  // error: mismatched types
	case uint32(789): // error: mismatched types
	}
}
</code></pre>
<p></p>
<h3 id="default-switch-expression-value" class="tmd-header-3">
The default switch expression of a <code class="tmd-code-span">switch</code> block is a typed value <code class="tmd-code-span">true</code> of the predeclared type <code class="tmd-code-span">bool</code>.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program will print <code class="tmd-code-span">true</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	switch { // &lt;=&gt; switch true {
	case true:  fmt.Println("true")
	case false: fmt.Println("false")
	}
}
</code></pre>
<p></p>
<h3 id="open-brace-on-the-next-line" class="tmd-header-3">
Sometimes, the open brace <code class="tmd-code-span">{</code> of an explicit code block can be put on the next line.
</h3>
<p></p>
<div class="tmd-usual">
For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	var i = 0
Outer:
	for
	{ %% okay on the next line
		switch
		{ %% okay on the next line
		case i == 5:
			break Outer
		default:
			i++
		}
	}
}
</code></pre>
<p></p>
<div class="tmd-usual">
What result will the following program print? <code class="tmd-code-span">true</code> or <code class="tmd-code-span">false</code>? The answer is <code class="tmd-code-span">true</code>. Please read <a href="line-break-rules.html">line break rules in Go</a> for reasons.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func False() bool {
	return false
}

func main() {
	switch False()
	{
	case true:  fmt.Println("true")
	case false: fmt.Println("false")
	}
}
</code></pre>
<p></p>
<h3 id="some-case-branch-blocks-must-be-explicit" class="tmd-header-3">
Some <code class="tmd-code-span">case</code> branch blocks must be explicit.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">func demo(n, m int) (r int) {
	switch n {
	case 123:
		if m &gt; 0 {
			goto End
		}
		r++

		End: // syntax error: missing statement after label
	default:
		r = 1
	}
	return
}
</code></pre>
<p></p>
<div class="tmd-usual">
To make it compile okay, the <code class="tmd-code-span">case</code> branch code block should be explicit:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">func demo(n, m int) (r int) {
	switch n {
	case 123: {
		if m &gt; 0 {
			goto End
		}
		r++

		End:
	}
	default:
		r = 1
	}
	return
}
</code></pre>
<p></p>
<div class="tmd-usual">
Alternatively, we can let a semicolon follow the label declaration <code class="tmd-code-span">End:</code>:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">func demo(n, m int) (r int) {
	switch n {
	case 123:
		if m &gt; 0 {
			goto End
		}
		r++

		End:;
	default:
		r = 1
	}
	return
}
</code></pre>
<p></p>
<div class="tmd-usual">
Please read <a href="line-break-rules.html">line break rules in Go</a> for reasons.
</div>
<p></p>
<h3 id="defer-modify-results" class="tmd-header-3">
A nested deferred function calls can modify return result values of its innermost nesting function.
</h3>
<p></p>
<div class="tmd-usual">
For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func F() (r int) {
	defer func() {
		r = 789
	}()

	return 123 // &lt;=&gt; r = 123; return
}

func main() {
	fmt.Println(F()) // 789
}
</code></pre>
<p></p>
<h3 id="no-op-recover-calls" class="tmd-header-3">
Some <code class="tmd-code-span">recover</code> calls may be no-ops.
</h3>
<p></p>
<div class="tmd-usual">
We should call the <code class="tmd-code-span">recover</code> function at the right places. Please read <a href="panic-and-recover-more.html">the right places to call the built-in <code class="tmd-code-span">recover</code> function</a> for details.
</div>
<p></p>
<p></p>
<h3 id="os-exit-runtime-goexit" class="tmd-header-3">
Exit a program with a <code class="tmd-code-span">os.Exit</code> function call and exit a goroutine with a <code class="tmd-code-span">runtime.Goexit</code> function call.
</h3>
<p></p>
<p></p>
<div class="tmd-usual">
We can exit a program from any function by calling the <code class="tmd-code-span">os.Exit</code> function. An <code class="tmd-code-span">os.Exit</code> function call takes an <code class="tmd-code-span">int</code> code as argument and returns the code to operating system.
</div>
<p></p>
<div class="tmd-usual">
An example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// exit-example.go
package main

import "os"
import "time"

func main() {
	go func() {
		time.Sleep(time.Second)
		os.Exit(1)
	}()
	select{}
}
</code></pre>
<p></p>
<div class="tmd-usual">
Run it:
</div>
<p></p>
<pre class="tmd-code output">
$ go run a.go
exit status 1
$ echo $?
1
</pre>
<p></p>
<div class="tmd-usual">
We can make a goroutine exit by calling the <code class="tmd-code-span">runtime.Goexit</code> function. The <code class="tmd-code-span">runtime.Goexit</code> function has no parameters.
</div>
<p></p>
<div class="tmd-usual">
In the following example, the <code class="tmd-code-span">Java</code> word will not be printed.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"
import "runtime"

func main() {
	c := make(chan int)
	go func() {
		defer func() {c &lt;- 1}()
		defer fmt.Println("Go")
		func() {
			defer fmt.Println("C")
			runtime.Goexit()
		}()
		fmt.Println("Java")
	}()
	&lt;-c
}
</code></pre>
<p></p>
<h3 id="some-operator-precedence" class="tmd-header-3">
The precedence of the increment operator <code class="tmd-code-span">++</code> and the decrement <code class="tmd-code-span">--</code> is lower than the dereference operator <code class="tmd-code-span">*</code> and the address-taking operator <code class="tmd-code-span">&amp;</code>, which are lower than the property selection operator <code class="tmd-code-span">.</code> in selectors.
</h3>
<p></p>
<div class="tmd-usual">
For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

type T struct {
	x int
	y *int
}

func main() {
	var t T
	p := &amp;t.x // &lt;=&gt; p := &amp;(t.x)
	fmt.Printf("%T\n", p) // *int

	*p++ // &lt;=&gt; (*p)++
	*p-- // &lt;=&gt; (*p)--

	t.y = p
	a := *t.y // &lt;=&gt; *(t.y)
	fmt.Printf("%T\n", a) // int
}
</code></pre>
<p></p>
<h3 id="type-deduction-in-bit-shift" class="tmd-header-3">
The type deduction rule for the left untyped operand of a bit-shift operation depends on whether or not the right operand is a constant.
</h3>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
}

const M  = 2
// Compiles okay. 1.0 is deduced as an int value.
var _ = 1.0 &lt;&lt; M

var N = 2
// Fails to compile. 1.0 is deduced as a float64 value.
var _ = 1.0 &lt;&lt; N
</code></pre>
<p></p>
<div class="tmd-usual">
Please read <a href="operators.html#bitwise-shift-left-operand-type-deduction">this article</a> for reasons.
</div>
<p></p>
<p></p>
<h3 id="conversion-of-pointers-with-different-underlying-types" class="tmd-header-3">
Values of two pointer types with different underlying types can be converted to each other if the base types of their underlying types share the same underlying type.
</h3>
<p></p>
<div class="tmd-usual">
An example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type MyInt int64
type Ta    *int64
type Tb    *MyInt

func main() {
	var a Ta
	var b Tb

	// Direct conversion is not allowed.
	//a = Ta(b) // error

	// But indirect conversion is possible.
	y := (*MyInt)(b)
	x := (*int64)(y)
	a = x           // &lt;=&gt; the next line
	a = (*int64)(y) // &lt;=&gt; the next line
	a = (*int64)((*MyInt)(b))
	_ = a
}
</code></pre>
<p></p>
<h3 id="addresses-of-zeor-sized-values" class="tmd-header-3">
Addresses of different zero-sized values may be equal, or not.
</h3>
<p></p>
<div class="tmd-usual">
Whether or not the addresses of two zero-sized values are equal is compiler and compiler version dependent.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	a := struct{}{}
	b := struct{}{}
	x := struct{}{}
	y := struct{}{}
	m := [10]struct{}{}
	n := [10]struct{}{}
	o := [10]struct{}{}
	p := [10]struct{}{}

	fmt.Println(&amp;x, &amp;y, &amp;o, &amp;p)

	// For the standard Go compiler (1.25.n),
	// x, y, o and p escape to heap, but
	// a, b, m and n are allocated on stack.

	fmt.Println(&amp;a == &amp;b) // false
	fmt.Println(&amp;x == &amp;y) // true
	fmt.Println(&amp;a == &amp;x) // false

	fmt.Println(&amp;m == &amp;n) // false
	fmt.Println(&amp;o == &amp;p) // true
	fmt.Println(&amp;n == &amp;p) // false
}
</code></pre>
<p></p>
<div class="tmd-usual">
The outputs indicated in the above code are for the standard Go compiler 1.25.n.
</div>
<p></p>
<h3 id="self-based-pointer-type" class="tmd-header-3">
The base type of a pointer type may be the pointer type itself.
</h3>
<p></p>
<div class="tmd-usual">
An example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	type P *P
	var p P
	p = &amp;p
	p = **************p
}
</code></pre>
<p></p>
<div class="tmd-usual">
Similarly,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
the element type of a slice type can be the slice type itself,
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the element type of a map type can be the map type itself,
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the element type of a channel type can be the channel type itself,
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
and the argument and result types of a function type can be the function type itself.
</div>
</li>
</ul>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	type S []S
	type M map[string]M
	type C chan C
	type F func(F) F

	s := S{0:nil}
	s[0] = s
	m := M{"Go": nil}
	m["Go"] = m
	c := make(C, 3)
	c &lt;- c; c &lt;- c; c &lt;- c
	var f F
	f = func(F)F {return f}

	_ = s[0][0][0][0][0][0][0][0]
	_ = m["Go"]["Go"]["Go"]["Go"]
	&lt;-&lt;-&lt;-c
	f(f(f(f(f))))
}
</code></pre>
<p></p>
<h3 id="pointer-selector-shorthands" class="tmd-header-3">
A detail about selector shorthands.
</h3>
<p></p>
<div class="tmd-usual">
For a pointer value, which type is either named or not, if the base type of its (pointer) type is a struct type, then we can select the fields of the struct value referenced by the pointer value through the pointer value. However, if the type of the pointer value is a named type, then we can't select the methods of the struct value referenced by the pointer value through the pointer value.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type T struct {
	x int
}
func (T) m(){} // T has one method.

type P *T  // a named one-level pointer type.
type PP *P // a named two-level pointer type.

func main() {
	var t T
	var tp = &amp;t
	var tpp = &amp;tp
	var p P = tp
	var pp PP = &amp;p
	tp.x = 12  // okay
	p.x = 34   // okay
	pp.x = 56  // error: type PP has no field or method x
	tpp.x = 78 // error: type **T has no field or method x

	tp.m()  // okay. Type *T also has a "m" method.
	p.m()   // error: type P has no field or method m
	pp.m()  // error: type PP has no field or method m
	tpp.m() // error: type **T has no field or method m
}
</code></pre>
<p></p>
<h3 id="composite-literal-simplification" class="tmd-header-3">
Sometimes, nested composite literals can be simplified.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="container.html#composite-literal-simplification">nested composite literals can be simplified</a> for details.
</div>
<p></p>
<p></p>
<h3 id="use-pointer-as-array" class="tmd-header-3">
In some scenarios, it is ok to use array pointers as arrays.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="container.html#use-pointer-as-array">use array pointers as arrays</a> for details.
</div>
<p></p>
<p></p>
<h3 id="nil-map-element-retrieving" class="tmd-header-3">
Retrieving elements from nil maps will not panic. The result is a zero element value.
</h3>
<p></p>
<div class="tmd-usual">
For example, the <code class="tmd-code-span">Foo1</code> and the <code class="tmd-code-span">Foo2</code> functions are equivalent, but the function <code class="tmd-code-span">Foo2</code> is much tidier than the function <code class="tmd-code-span">Foo1</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">func Foo1(m map[string]int) int {
	if m != nil {
		return m["foo"]
	}
	return 0
}

func Foo2(m map[string]int) int {
	return m["foo"]
}
</code></pre>
<p></p>
<h3 id="nil-map-element--deletion" class="tmd-header-3">
Deleting an entry from a nil map will not panic. It is a no-op.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program will not panic.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	var m map[string]int // nil
	delete(m, "foo")
}
</code></pre>
<p></p>
<h3 id="append-slice-elements" class="tmd-header-3">
The result slice of an <code class="tmd-code-span">append</code> function call may share some elements with the original slice, or not.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="container.html#element-addition-deletion">append and delete container elements</a> for details.
</div>
<p></p>
<p></p>
<h3 id="subslice" class="tmd-header-3">
The length of a subslice may be larger than the base slice the subslice derives from.
</h3>
<p></p>
<div class="tmd-usual">
For example,
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	s := make([]int, 3, 9)
	fmt.Println(len(s)) // 3
	s2 := s[2:7]
	fmt.Println(len(s2)) // 5
}
</code></pre>
<p></p>
<div class="tmd-usual">
Please read <a href="container.html#subslice">derive slices from arrays and slices</a> for details.
</div>
<p></p>
<p></p>
<h3 id="derive-from-nil-slice" class="tmd-header-3">
Deriving a subslice from a nil slice is ok if all the indexes used in the subslice expression are zero. The result subslice is also a nil slice.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program will not panic at run time.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	var x []int // nil
	a := x[:]
	b := x[0:0]
	c := x[:0:0]
	// Print three "true".
	fmt.Println(a == nil, b == nil, c == nil)
}
</code></pre>
<p></p>
<div class="tmd-usual">
Please read <a href="container.html#subslice">derive slices from arrays and slices</a> for details.
</div>
<p></p>
<h3 id="range-over-nil-map-and-slice" class="tmd-header-3">
Ranging over a nil maps or a nil slices is ok, it is a no-op.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program compiles okay.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	var s []int // nil
	for range s {
	}

	var m map[string]int // nil
	for range m {
	}
}
</code></pre>
<p></p>
<h3 id="range-over-nil-array-pointer" class="tmd-header-3">
Range over a nil array pointer is ok if the second iteration variable is ignored or omitted.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program will print <code class="tmd-code-span">01234</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	var a *[5]int // nil
	for i, _ := range a {
		fmt.Print(i)
	}
}
</code></pre>
<p></p>
<h3 id="modify-slice-length-and-capacity-separately" class="tmd-header-3">
The length and capacity of a slice can be modified separately.
</h3>
<p></p>
<div class="tmd-usual">
We can modify the length and capacity of a slice separately through the reflection way. Please read <a href="container.html#modify-slice-length-and-capacity">modify the length and capacity properties of a slice individually</a> for details.
</div>
<p></p>
<p></p>
<h3 id="indexes-in-composite-literals" class="tmd-header-3">
The indexes in slice and array composite literals must be constants and non-negative.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following code fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">var k = 1
// error: index must be non-negative integer constant
var x = [2]int{k: 1}
// error: index must be non-negative integer constant
var y = []int{k: 1}
</code></pre>
<p></p>
<div class="tmd-usual">
Note, the keys in map composite literals are not required to be constants.
</div>
<p></p>
<h3 id="constant-keys-in-composite-literals" class="tmd-header-3">
The constant indexes or keys in slice/array/map composite literals can't be duplicate.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following code fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">// error: duplicate index in array literal: 1
var a = []bool{0: false, 1: true, 1: true}
// error: duplicate index in array literal: 0
var b = [...]string{0: "foo", 1: "bar", 0: "foo"}
// error: duplicate key "foo" in map literal
var c = map[string]int{"foo": 1, "foo": 2}
</code></pre>
<p></p>
<div class="tmd-usual">
This feature can be used to <a href="tips.html#assert-at-compile-time">assert some conditions at compile time</a>.
</div>
<p></p>
<p></p>
<h3 id="array-slice-element-addressability" class="tmd-header-3">
Elements of unaddressable arrays are also unaddressable, but elements of unaddressable slices are always addressable.
</h3>
<p></p>
<div class="tmd-usual">
The reason is the elements of an array value and the array will be stored in the same memory block when the array is stored in memory. But <a href="unofficial-faq.html#slice-elements-always-addressable">the situation is different for slices</a>.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
An example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	// Container composite literals are unaddressable.

	// It is ok to take slice literal element addresses.
	_ = &amp;[]int{1}[0] // ok
	// Cannot take addresses of array literal elements.
	_ = &amp;[5]int{}[0] // error

	// It is ok to modify slice literal elements.
	[]int{1,2,3}[1] = 9  // ok
	// Cannot modify array literal elements.
	[3]int{1,2,3}[1] = 9 // error
}
</code></pre>
<p></p>
<h3 id="array-slice-derivable" class="tmd-header-3">
It is ok to derive subslices from unaddressable slices, but not ok from unaddressable arrays.
</h3>
<p></p>
<div class="tmd-usual">
The reason is the same as the last detail.
</div>
<p></p>
<div class="tmd-usual">
An example:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	// Map elements are unaddressable in Go.

	// The following lines compile okay. Deriving
	// slices from unaddressable slices is allowed.
	_ = []int{6, 7, 8, 9}[1:3]
	var ms = map[string][]int{"abc": {0, 1, 2, 3}}
	_ = ms["abc"][1:3]

	// The following lines fail to compile. Deriving
	// slices from unaddressable arrays is not allowed.
	/*
	_ = [...]int{6, 7, 8, 9}[1:3] // error
	var ma = map[string][4]int{"abc": {0, 1, 2, 3}}
	_ = ma["abc"][1:3]  // error
	*/
}
</code></pre>
<p></p>
<h3 id="nan-as-map-keys" class="tmd-header-3">
Putting entries with <code class="tmd-code-span">NaN</code> as keys to a map is like putting the entries in a black hole.
</h3>
<p></p>
<div class="tmd-usual">
This reason is <code class="tmd-code-span">NaN != NaN</code>, which is another detail will be described <a href="#nan-inf">below</a>. Before Go 1.12, the elements with <code class="tmd-code-span">NaN</code> as keys can only be found out in a <code class="tmd-code-span">for-range</code> loop, Since Go 1.12, the elements with <code class="tmd-code-span">NaN</code> as keys can also be printed out by <code class="tmd-code-span">fmt.Print</code> alike functions.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"
import "math"

func main() {
	var a = math.NaN()
	fmt.Println(a) // NaN

	var m = map[float64]int{}
	m[a] = 123
	v, present := m[a]
	fmt.Println(v, present) // 0 false
	m[a] = 789
	v, present = m[a]
	fmt.Println(v, present) // 0 false

	fmt.Println(m) // map[NaN:789 NaN:123]
	delete(m, a)   // no-op
	fmt.Println(m) // map[NaN:789 NaN:123]

	for k, v := range m {
		fmt.Println(k, v)
	}
	// the above loop outputs:
	// NaN 123
	// NaN 789
}
</code></pre>
<p></p>
<div class="tmd-usual">
Please note, before Go 1.12, the two <code class="tmd-code-span">fmt.Println(m)</code> calls both printed <code class="tmd-code-span">map[NaN:&lt;nil&gt; NaN:&lt;nil&gt;]</code>.
</div>
<p></p>
<h3 id="capacity-of-slice-from-string" class="tmd-header-3">
The capacity of the result slice of a conversion from a string to byte/rune slice may be larger than the length of the result slice.
</h3>
<p></p>
<div class="tmd-usual">
We should not assume the length and the capacity of the result slice are always equal.
</div>
<p></p>
<div class="tmd-usual">
In the following example, if the last <code class="tmd-code-span">fmt.Println</code> line is removed, the outputs of the two lines before it print the same value <code class="tmd-code-span">5</code>; otherwise, one print <code class="tmd-code-span">5</code> and one print <code class="tmd-code-span">8</code> (for the standard Go compiler 1.25.n).
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	s := "abcde"
	x := []byte(s)              // len(s) == 1
	fmt.Println(cap([]byte(s))) // 32
	fmt.Println(cap(x))         // 8
	fmt.Println(x)
}
</code></pre>
<p></p>
<div class="tmd-usual">
<a href="https://github.com/go101/go101/wiki/The-capacity-of-the-result-byte-%28or-rune%29-slice-of-a-conversion-from-a-string-is-undefined">Some buggy code will be written</a> if we assume the length and the capacity of the result slice are always equal.
</div>
<p></p>
<p></p>
<h3 id="different-loops" class="tmd-header-3">
For a slice <code class="tmd-code-span">s</code>, the loop <code class="tmd-code-span">for i = range s {...}</code> is not equivalent to the loop <code class="tmd-code-span">for i = 0; i &lt; len(s); i++ {...}</code>.
</h3>
<p></p>
<div class="tmd-usual">
The respective final values of the iteration variable <code class="tmd-code-span">i</code> may be different for the two loops.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

var i int

func fa(s []int, n int) int {
	i = n
	for i = 0; i &lt; len(s); i++ {}
	return i
}

func fb(s []int, n int) int {
	i = n
	for i = range s {}
	return i
}

func main() {
	s := []int{2, 3, 5, 7, 11, 13}
	fmt.Println(fa(s, -1), fb(s, -1)) // 6 5
	s = nil
	fmt.Println(fa(s, -1), fb(s, -1)) // 0 -1
}
</code></pre>
<p></p>
<h3 id="map-entry-iteration" class="tmd-header-3">
The iteration order over maps is not guaranteed to be the same from one iteration to the next.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following program will not run infinitely:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func f(m map[byte]byte) string {
	bs := make([]byte, 0, 2*len(m))
	for k, v := range m {
		bs = append(bs, k, v)
	}
	return string(bs)
}

func main() {
	m := map[byte]byte{'a':'A', 'b':'B', 'c':'C'}
	s0 := f(m)
	for i := 1; ; i++{
		if s := f(m); s != s0 {
			fmt.Println(s0)
			fmt.Println(s)
			fmt.Println(i)
			return
		}
	}
}
</code></pre>
<p></p>
<div class="tmd-usual">
Please note, the entries in the JSON marshal result on maps are sorted by their keys. And since Go 1.12, printing maps (with the print functions in the standard <code class="tmd-code-span">fmt</code> package) also results sorted entries.
</div>
<p></p>
<h3 id="create-entry-in-map-entry-iteration" class="tmd-header-3">
If a map entry is created during an iteration of the map, that entry may be iterated during the iteration or may be skipped.
</h3>
<p></p>
<div class="tmd-usual">
A proof:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	m := map[int]int{0: 0, 1: 100, 2: 200}
	r, n, i:= len(m), len(m), 0
	for range m {
		m[n] = n*100
		n++
		i++
	}
	fmt.Printf("%d new entries, iterate %d and skip %d\n",
		i, i - r, n - i,
	)
}
</code></pre>
<p></p>
<div class="tmd-usual">
Thanks to Valentin Deleplace for the above <a href="https://twitter.com/val_deleplace/status/1358784287399698434">two detail suggestions</a>.
</div>
<p></p>
<p></p>
<h3 id="call-as-expression" class="tmd-header-3">
A multi-result function call can't mix with other expressions when the call is used as the sources in an assignment or the arguments of another function call.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="function.html#call-as-expression">use function calls as expressions</a> for details.
</div>
<p></p>
<p></p>
<h3 id="compile-time-evaluated-calls" class="tmd-header-3">
Some function calls are evaluated at compile time.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="function.html#compile-time-evaluated-calls">some function calls are evaluated at compile time</a> for details.
</div>
<p></p>
<p></p>
<h3 id="method-as-function" class="tmd-header-3">
Each method corresponds to an implicit function.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="method.html#method-as-function">each method corresponds to an implicit function</a> for details.
</div>
<p></p>
<p></p>
<h3 id="comparison-interfaces-may-panic" class="tmd-header-3">
Comparing two interface values with the same dynamic incomparable type produces a panic.
</h3>
<p></p>
<div class="tmd-usual">
For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	var x interface{} = []int{}
	_ = x == x // panic
}
</code></pre>
<p></p>
<h3 id="type-assertion-to-interface-type" class="tmd-header-3">
Type assertions can be used to convert a value of an interface type to another interface type, even if the former interface type doesn't implement the latter one.
</h3>
<p></p>
<div class="tmd-usual">
For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type Foo interface {
	foo()
}

type T int
func (T) foo() {}

func main() {
	var x interface{} = T(123)
	// The following two lines fails to compile, for the
	// same reason: interface{} does not implement Foo.
	/*
	var _ Foo = x   // error
	var _ = Foo(x)  // error
	*/
	// But the following line compiles and runs okay.
	var _ = x.(Foo) // okay
}
</code></pre>
<p></p>
<h3 id="failed-type-assertion-may-panic" class="tmd-header-3">
Whether or not the second optional result of a type assertion is present will affect the behavior of the type assertion.
</h3>
<p></p>
<div class="tmd-usual">
If the second optional result presents in a failed type assertion, the type assertion will not produce a panic. Otherwise, a panic will occur. For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	var x interface{} = true

	// Assertion fails, but doesn't cause a panic.
	_, _ = x.(int)

	// Assertion fails, which causes a panic.
	_ = x.(int)
}
</code></pre>
<p></p>
<h3 id="impossible-to-interface-assertion" class="tmd-header-3">
About the impossible to-interface assertions which can be detected at compile time.
</h3>
<p></p>
<div class="tmd-usual">
At compile time, some to-interface assertions can be deducted as impossible to succeed. For example, the assertion shown in the following code:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type Ia interface {
	m()
}

type Ib interface {
	m() int
}

type T struct{}

func (T) m() {}

func main() {
	var x Ia = T{}
	_ = x.(Ib) // panic: main.T is not main.Ib
}
</code></pre>
<p></p>
<div class="tmd-usual">
Such assertions will not make code compilations fail (but the program will panic at run time). Since Go Toolchain 1.15, the <code class="tmd-code-span">go vet</code> command warns on such assertions.
</div>
<p></p>
<p></p>
<h3 id="errors-new-different-returns" class="tmd-header-3">
Two <code class="tmd-code-span">error</code> values returned by two <code class="tmd-code-span">errors.New</code> calls with the same argument are not equal.
</h3>
<p></p>
<div class="tmd-usual">
The reason is the <code class="tmd-code-span">errors.New</code> function will copy the input string argument and use a pointer to the copied string as the dynamic value of the returned <code class="tmd-code-span">error</code> value. Two different calls will produce two different pointers.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"
import "errors"

func main() {
	notfound := "not found"
	a, b := errors.New(notfound), errors.New(notfound)
	fmt.Println(a == b) // false
}
</code></pre>
<p></p>
<h3 id="receive-only-channel-canot-be-closed" class="tmd-header-3">
Receive-only channels can't be closed.
</h3>
<p></p>
<div class="tmd-usual">
For example, the following code fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
}

func foo(c &lt;-chan int) {
	close(c) // error: cannot close receive-only channel
}
</code></pre>
<p></p>
<h3 id="send-to-closed-channel-is-non-blocking" class="tmd-header-3">
Sending a value to a closed channel is viewed as a non-blocking operation, and this operation causes a panic.
</h3>
<p></p>
<div class="tmd-usual">
For example, in the following program, when the second <code class="tmd-code-span">case</code> branch gets selected, it will produce a panic at run time.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	var c = make(chan bool)
	close(c)
	select {
	case &lt;-c:
	case c &lt;- true: // panic: send on closed channel
	default:
	}
}
</code></pre>
<p></p>
<h3 id="local-type-declaration" class="tmd-header-3">
Types can be declared within function bodies.
</h3>
<p></p>
<div class="tmd-usual">
Types can be declared in function bodies. For example,
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func main() {
	type T struct{}
	type S = []int
}
</code></pre>
<p></p>
<h3 id="final-zero-size-field" class="tmd-header-3">
For the standard compiler, zero-sized fields in a struct may be treated as one-byte-sized value.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="unofficial-faq.html#final-zero-size-field">this FAQ item</a> for details.
</div>
<p></p>
<p></p>
<h3 id="nan-inf" class="tmd-header-3">
NaN != NaN, Inf == Inf.
</h3>
<p></p>
<div class="tmd-usual">
This follows IEEE-754 standard and is consistent with most other programming languages:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"
import "math"

func main() {
	var a = math.Sqrt(-1.0)
	fmt.Println(a)      // NaN
	fmt.Println(a == a) // false

	var x = 0.0
	var y = 1.0 / x
	var z = 2.0 * y
	fmt.Println(y, z, y == z) // +Inf +Inf true
}
</code></pre>
<p></p>
<h3 id="non-exported-names-from-different-packages" class="tmd-header-3">
Non-exported method names and struct field names from different packages are viewed as different names.
</h3>
<p></p>
<div class="tmd-usual">
For example, if the following types are declared in package <code class="tmd-code-span">foo</code>:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package foo

type I = interface {
	about() string
}

type S struct {
	a string
}

func (s S) about() string {
	return s.a
}
</code></pre>
<p></p>
<div class="tmd-usual">
and the following types are declared in package <code class="tmd-code-span">bar</code>:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package bar

type I = interface {
	about() string
}

type S struct {
	a string
}

func (s S) about() string {
	return s.a
}
</code></pre>
<p></p>
<div class="tmd-usual">
then,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
values of the two respective types <code class="tmd-code-span">S</code> from the two packages can't be converted to each other.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the two respective interface types <code class="tmd-code-span">S</code> from the two packages denote two distinct method sets.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
type <code class="tmd-code-span">foo.S</code> doesn't implement the interface type <code class="tmd-code-span">bar.I</code>.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
type <code class="tmd-code-span">bar.S</code> doesn't implement the interface type <code class="tmd-code-span">foo.I</code>.
</div>
</li>
</ul>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "包2/foo"
import "包2/bar"

func main() {
	var x foo.S
	var y bar.S
	var _ foo.I = x
	var _ bar.I = y

	// The following lines fail to compile.
	x = foo.S(y)
	y = bar.S(x)
	var _ foo.I = y
	var _ bar.I = x
}
</code></pre>
<p></p>
<p></p>
<h3 id="blank-fields-are-ignored-in-comparisons" class="tmd-header-3">
In struct value comparisons, blank fields will be ignored.
</h3>
<p></p>
<div class="tmd-usual">
Blank fields are those fields whose name are the blank identifier <code class="tmd-code-span">_</code>. The following program will print <code class="tmd-code-span">true</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

type T struct {
	_ int
	_ bool
}

func main() {
	var t1 = T{123, true}
	var t2 = T{789, false}
	fmt.Println(t1 == t2) // true
}
</code></pre>
<p></p>
<h3 id="sometimes-parentheses-are-required" class="tmd-header-3">
Parentheses are required in several rare scenarios to make code compile okay.
</h3>
<p></p>
<div class="tmd-usual">
For example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

type T struct{x, y int}

func main() {
	// Each of the following three lines makes code
	// fail to compile. Some "{}"s confuse compilers.
	/*
	if T{} == T{123, 789} {}
	if T{} == (T{123, 789}) {}
	if (T{}) == T{123, 789} {}
	var _ = func()(nil) // nil is viewed as a type
	*/

	// We must add parentheses like the following
	// two lines to make code compile okay.
	if (T{} == T{123, 789}) {}
	if (T{}) == (T{123, 789}) {}
	var _ = (func())(nil) // nil is viewed as a value
}
</code></pre>
<p></p>
<p></p>
<h3 id="stack-overflow-is-unrecoverable" class="tmd-header-3">
Stack overflow is not panic.
</h3>
<p></p>
<div class="tmd-usual">
For the current main stream Go compilers, stack overflows are fatal errors. Once a stack overflow happens, the whole program will crash without recovery ways.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

func f() {
	f()
}

func main() {
	defer func() {
		recover() // helpless to avoid program crashing
	}()
	f()
}
</code></pre>
<p></p>
<div class="tmd-usual">
the running result:
</div>
<p></p>
<pre class="tmd-code output">
runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

runtime stack:
...
</pre>
<p></p>
<div class="tmd-usual">
About more crash cases, please read <a href="https://github.com/go101/go101/wiki/Panic-and-crash-cases">this wiki article</a>.
</div>
<p></p>
<p></p>
<h3 id="some-evaluation-order-are-compiler-dependent" class="tmd-header-3">
Some expression evaluation orders in Go are compiler implementation dependent.
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="evaluation-orders.html">expression evaluation orders in Go</a> for details.
</div>
<p></p>
<p></p>
<h3 id="reflect-deep-equal" class="tmd-header-3">
The results of <code class="tmd-code-span">reflect.DeepEqual(x, y)</code> and <code class="tmd-code-span">x == y</code> may be different.
</h3>
<p></p>
<div class="tmd-usual">
The function call <code class="tmd-code-span">reflect.DeepEqual(x, y)</code> will always return <code class="tmd-code-span">false</code> if the types of its two arguments are different, whereas <code class="tmd-code-span">x == y</code> may return <code class="tmd-code-span">true</code> even if the types of the two operands are different.
</div>
<p></p>
<div class="tmd-usual">
The second difference is a <code class="tmd-code-span">DeepEqual</code> call with two pointer argument values of the same type returns whether or not the two respective values referenced by the two pointers are deep equal. So the call might return <code class="tmd-code-span">true</code> even if the two pointers are not equal.
</div>
<p></p>
<div class="tmd-usual">
The third difference is the result of a <code class="tmd-code-span">DeepEqual</code> call might return <code class="tmd-code-span">true</code> if both of its arguments are in cyclic reference chains (to avoid infinite looping in the call).
</div>
<p></p>
<div class="tmd-usual">
The fourth difference is, the function call <code class="tmd-code-span">reflect.DeepEqual(x, y)</code> is not expected to panic generally, whereas <code class="tmd-code-span">x == y</code> will panic if the two operands are both interface values and their dynamic types are identical and incomparable.
</div>
<p></p>
<div class="tmd-usual">
An example showing these differences:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"fmt"
	"reflect"
)

func main() {
	type Book struct {page int}
	x := struct {page int}{123}
	y := Book{123}
	fmt.Println(reflect.DeepEqual(x, y)) // false
	fmt.Println(x == y)                  // true

	z := Book{123}
	fmt.Println(reflect.DeepEqual(&amp;z, &amp;y)) // true
	fmt.Println(&amp;z == &amp;y)                  // false

	type Node struct{peer *Node}
	var q, r, s Node
	q.peer = &amp;q // form a cyclic reference chain
	r.peer = &amp;s // form a cyclic reference chain
	s.peer = &amp;r
	println(reflect.DeepEqual(&amp;q, &amp;r)) // true
	fmt.Println(q == r)                // false

	var f1, f2 func() = nil, func(){}
	fmt.Println(reflect.DeepEqual(f1, f1)) // true
	fmt.Println(reflect.DeepEqual(f2, f2)) // false

	var a, b interface{} = []int{1, 2}, []int{1, 2}
	fmt.Println(reflect.DeepEqual(a, b)) // true
	fmt.Println(a == b)                  // panic
}
</code></pre>
<p></p>
<div class="tmd-usual">
Note, if the two arguments of a <code class="tmd-code-span">DeepEqual</code> call are both function values, then the call returns <code class="tmd-code-span">true</code> only if the two function arguments are both nil and their types are identical. It is similar to compare container values whose elements contain function values or compare struct values whose fields contain function values. But please also note that the result of comparing two slices (of the same type) is always <code class="tmd-code-span">true</code> if the two slices exactly share the same elements (in other words, they have the same length and each pair of their corresponding elements have the same address). An example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"fmt"
	"reflect"
)

func main() {
	a := [1]func(){func(){}}
	b := a
	fmt.Println(reflect.DeepEqual(a, a))       // false
	fmt.Println(reflect.DeepEqual(a[:], a[:])) // true
	fmt.Println(reflect.DeepEqual(a[:], b[:])) // false
	a[0], b[0] = nil, nil
	fmt.Println(reflect.DeepEqual(a[:], b[:])) // true
}
</code></pre>
<p></p>
<h3 id="reflect-value-bytes" class="tmd-header-3">
The <code class="tmd-code-span">reflect.Value.Bytes()</code> method returns a <code class="tmd-code-span">[]byte</code> value, which element type, <code class="tmd-code-span">byte</code>, might be not the same as the Go slice value represented by the receiver parameter.
</h3>
<p></p>
<div class="tmd-usual">
Assume the underlying type of a defined type <code class="tmd-code-span">MyByte</code> is the predeclared type <code class="tmd-code-span">byte</code>, we know that Go type system forbids the conversions between <code class="tmd-code-span">[]MyByte</code> and <code class="tmd-code-span">[]byte</code> values. However, it looks the implementation of the method <code class="tmd-code-span">Bytes</code> of the <code class="tmd-code-span">reflect.Value</code> type partially violates this restriction unintentionally, by allowing converting a <code class="tmd-code-span">[]MyByte</code> value to <code class="tmd-code-span">[]byte</code>.
</div>
<p></p>
<div class="tmd-usual">
Example:
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "bytes"
import "fmt"
import "reflect"

type MyByte byte

func main() {
	var mybs = []MyByte{'a', 'b', 'c'}
	var bs []byte

	// bs = []byte(mybs) // this line fails to compile

	v := reflect.ValueOf(mybs)
	bs = v.Bytes() // okay. Violating Go type system.
	fmt.Println(bytes.HasPrefix(bs, []byte{'a', 'b'})) // true

	bs[1], bs[2] = 'r', 't'
	fmt.Printf("%s \n", mybs) // art
}
</code></pre>
<p></p>
<div class="tmd-usual">
But it looks the violation is not harmful. On the contrary, it makes some benefits. For example, with this violation, we can use the functions in the <code class="tmd-code-span">bytes</code> standard package for the <code class="tmd-code-span">[]MyByte</code> values.
</div>
<p></p>
<div class="tmd-usual">
Note, the <code class="tmd-code-span">reflect.Value.Bytes()</code> method <a href="https://github.com/golang/go/issues/27727">might be removed later</a>.
</div>
<p></p>
<p></p>
<h3 id="check-file-existent" class="tmd-header-3">
We should use <code class="tmd-code-span">os.IsNotExist(err)</code> instead of <code class="tmd-code-span">err == os.ErrNotExist</code> to check whether or not a file exists.
</h3>
<p></p>
<div class="tmd-usual">
Using <code class="tmd-code-span">err == os.ErrNotExist</code> may miss errors.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"fmt"
	"os"
)

func main() {
	_, err := os.Stat("a-nonexistent-file.abcxyz")
	fmt.Println(os.IsNotExist(err))    // true
	fmt.Println(err == os.ErrNotExist) // false
}
</code></pre>
<p></p>
<div class="tmd-usual">
For projects only supporting Go 1.13+, <code class="tmd-code-span">errors.Is(err, os.ErrNotExist)</code> is <a href="https://github.com/golang/go/issues/38198">more recommended to be used</a> to check whether or not a file exists.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"errors"
	"fmt"
	"os"
)

func main() {
	_, err := os.Stat("a-nonexistent-file.abcxyz")
	fmt.Println(errors.Is(err, os.ErrNotExist)) // true
}
</code></pre>
<p></p>
<h3 id="boolean-flag" class="tmd-header-3">
The <code class="tmd-code-span">flag</code> standard package treats boolean command flags differently than integer and string flags.
</h3>
<p></p>
<div class="tmd-usual">
There are three forms to pass flag options.
</div>
<ol class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">-flag</code>, for boolean flags only.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">-flag=x</code>, for any flag.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">-flag x</code>, for non-boolean flags only.
</div>
</li>
</ol>
<p></p>
<div class="tmd-usual">
And please note that, a boolean flag with the first form is viewed as the last flag, all items following it are viewed as arguments.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"
import "flag"

var b = flag.Bool("b", true, "a boolean flag")
var i = flag.Int("i", 123, "an integer flag")
var s = flag.String("s", "hi", "a string flag")

func main() {
	flag.Parse()
	fmt.Print("b=", *b, ", i=", *i, ", s=", *s, "\n")
	fmt.Println("arguments:", flag.Args())
}
</code></pre>
<p></p>
<div class="tmd-usual">
If we run this program with the below shown flags and arguments
</div>
<p></p>
<pre class="tmd-code output">
./exampleProgram -b false -i 789 -s bye arg0 arg1
</pre>
<p></p>
<div class="tmd-usual">
the output will be
</div>
<p></p>
<pre class="tmd-code output">
b=true, i=123, s=hi
arguments: [false -i 789 -s bye arg0 arg1]
</pre>
<p></p>
<div class="tmd-usual">
This output is obviously not what we expect.
</div>
<p></p>
<div class="tmd-usual">
We should pass the flags and arguments like
</div>
<p></p>
<pre class="tmd-code output">
./exampleProgram -b=false -i 789 -s bye arg0 arg1
</pre>
<p></p>
<div class="tmd-usual">
or
</div>
<p></p>
<pre class="tmd-code output">
./exampleProgram -i 789 -s bye -b arg0 arg1
</pre>
<p></p>
<div class="tmd-usual">
to get the output we expect:
</div>
<p></p>
<pre class="tmd-code output">
b=true, i=789, s=bye
arguments: [arg0 arg1]
</pre>
<p></p>
<p></p>
<h3 id="printf-positional-arguments" class="tmd-header-3">
<code class="tmd-code-span">[Sp|Fp|P]rintf</code> functions support positional arguments.
</h3>
<p></p>
<div class="tmd-usual">
The following program will print <code class="tmd-code-span">coco</code>.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	// The next line prints: coco
	fmt.Printf("%[2]v%[1]v%[2]v%[1]v", "o", "c")
}
</code></pre>
<p></p>
</div>
<p></p>
</div>
